Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Disk Arrays

As was true when you tried to lay out a batch processing system on traditional disks, the optimal layout is constrained by number of “it depends.” Read these guidelines, use what will work for you, and discard the rest. A minimal configuration should look something like this:


Element (# of Volumes) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries. If possible, mirror this disk for additional fault tolerance.
Redo log (0) Light update activity. If there is little update activity, the redo log files do not see very much I/O and are not a bottleneck. The redo log files can reside on the same disk as the system to save space; reallocate the disks for data files (if you do this, I recommend mirroring the OS volume).
Redo log (1+) Moderate to heavy update activity. If there is moderate to heavy update activity, it is much more important to protect the redo logs and provide for some sort of fault tolerance. This volume should be made up of at least two physical disks using RAID-1. By using only one log volume, performance degrades during archiving because the sequential nature of the log writes is disrupted. But with a batch system, if your redo log is large enough, archiving can be deferred until after the batch transactions are complete.
Archive logs (0) Light update activity. As with the redo log files, archiving is minimal and not necessary. The archive log files can also reside on the system disk.
Archive logs (1+) Moderate to heavy update activity. As with the redo log files, if updates are done on this system, you must provide for the sequential nature of the archive log files. This data can be written to tape as necessary.
Data and index files (1+) Parallel Query option. The number of disks used for data is determined by the amount of random I/Os generated by the transactions. If you use the Parallel Query option, you should share the drives between index and data.
Data files (1+) The number of disks you need for data is determined by the amount of random I/O your user community generates.
Index files (1+) The number of disks needed for indexes is determined by the size of the indexes and the number of I/Os to the indexes.

Both the data files and the indexes should be striped over as many disk drives as necessary to achieve optimal I/O rates on those disks. From Chapter 14, “Advanced Disk I/O Concepts,” remember that you can push a disk drive only to a maximum random I/O rate.


NOTE:  Batch processing systems differ from both OLTP and decision support systems in that I recommend separating the index and data files onto different logical striped volumes. I make this recommendation because of the time constraints and frequency of index creations. If you use the Parallel Index Creation feature in the Oracle Parallel Query option, these I/Os are randomized; you are better off sharing data and index volumes to maximize the number of disks and spread out random I/O. I also recommend that you use the Parallel Query option.

Unlike traditional disk drives, a disk array automatically stripes the data among all the disk drives. Therefore, you have to create only one tablespace and table for all your data. Although it is not necessary to put indexes into another tablespace, I recommend doing so for other reasons (such as monitoring and maintenance).

With traditional disk partitioning, it is difficult to manage hundreds of data files and hundreds of disks; with a disk array, on the other hand, it is possible to manage hundreds of disks with just a few data files. Of course, Oracle has a 2-gigabyte limitation on the size of a data file, but this is easily resolved by creating a data file for every 2 gigabytes of space you need. The data files can all reside on the same disk array volume. By splitting tablespaces into several data files with tables striped across them (even if they reside on the same logical volume), you are also better able to take advantage of the Parallel Query option.

When you use a disk array, many of the management and load-balancing tasks are greatly simplified. You also have the option of using fault tolerance without affecting system performance. Of course, using fault tolerance requires significantly more disks.

I recommend that you use a disk array if possible. Software striping is fine, but if your system is under heavy loads—as it is in most batch processing activities—you are better off offloading that overhead to a hardware RAID controller.

Hardware Considerations

Consider these factors when choosing hardware to use for batch processing:

  Low user load. Not very many concurrent processes/threads simultaneously access the system (unless you take advantage of the Parallel Query option).
  High I/O load. I/Os may be a mixture of random and sequential, depending on the type of transactions.
  Low network traffic during transaction processing, high network load during data load/unload.

If you can take advantage of the Oracle Parallel Query option, many different processes will use the machine at once; an SMP or MPP machine should scale very well. Because an SMP architecture uses CPUs based on the processes that are available to be run, if you always have a runnable process available for each CPU, you should see good scaling by adding additional processors. With an MPP machine, you see a similar effect but on a much larger scale.

If you have many concurrent accesses to the disks, you benefit from a disk array. I prefer hardware striping to OS striping because hardware striping does not incur any additional overhead for the operating system and does not take up valuable CPU cycles. If hardware striping is not available, OS striping is a good alternative.

During transaction processing, there is no significant network traffic, but during the load and unload processes, you may see significant network activity. If you use a high-speed network interface such as 100Base-T or fiber optics, you will see increased throughput during the load and unload processes.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.